Re: access(2)--a security hole?

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Julian Assange: "Re: access(2)--a security hole?"
• Previous message: Dave Goldberg: "Re: access(2)--a security hole?"
• In reply to: Jonathan M. Bresler: "access(2)--a security hole?"
• Next in thread: der Mouse: "Re: access(2)--a security hole?"

>
>
>the FreeBSD man page for access(2) includes a section titled "CAVEAT" 
>which says that "Access() is a potential security hole and should never 
>be used."
>
>i looked into libc source and access is a typical system call--no real 
>source at all, just enough assembler wrapper to generate a system call 
>with the correct arguments.  the assembler is generated when libc is 
>compiled through defines and other macros--real slick.
>
>the actual syscall is executed in /sys/kern/vfs_syscalls.c, but i cant 
>see why this is a hole.
>
>can you enlighten me?

access(2) is a security hole because the information it returns you is what
was true, not was is currently true. This has bitten a lot of programs
xterm being one that comes to mind. BAsically using access to check file
perms of any sort is just asking for trouble since between the time access
returns and the next line of your code, those permissions and/or the file
itself may have changed.

Basically, access should never be used in any setuid program for any purpose
really. As a matter of fact, I'm not real fond of it for any use since
it's unreliable at best and leads people to beleive something is true now
that was only true once for a possible short period of time.

James

• Next message: Julian Assange: "Re: access(2)--a security hole?"
• Previous message: Dave Goldberg: "Re: access(2)--a security hole?"
• In reply to: Jonathan M. Bresler: "access(2)--a security hole?"
• Next in thread: der Mouse: "Re: access(2)--a security hole?"